copyin_link() tries to allocate (unsigned int)c_filesize + 1 bytes.
If c_filesize == UINT_MAX, this works out as 0 bytes, resulting in a
null pointer and a subsequent SIGSEGV.
The previous commit made this impossible on 32-bit systems.
CVE-2021-31871
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Gbp-Pq: Name 0040-klibc-cpio-Fix-possible-crash-on-64-bit-systems.patch
The maximum name and file sizes in the "new" header format are 32-bit
unsigned values. However, the I/O functions mostly use long for sizes
and offsets, so that sizes >= 2^31 are handled wrongly on 32-bit
systems.
The current GNU cpio code doesn't seem to have this problem, but the
divergence between this version and that is large enough that I can't
simply cherry-pick a fix for it.
As a short-term fix, in read_in_new_ascii(), fail if c_namesize or
c_filesize is > LONG_MAX.
CVE-2021-31872
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Gbp-Pq: Name 0039-klibc-cpio-Fix-possible-integer-overflow-on-32-bit-s.patch
calloc() multiplies its 2 arguments together and passes the result to
malloc(). Since the factors and product both have type size_t, this
can result in an integer overflow and subsequent buffer overflow.
Check for this and fail if it happens.
CVE-2021-31870
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Gbp-Pq: Name 0037-klibc-calloc-Fail-if-multiplication-overflows.patch
malloc() adds some overhead to the requested size, which may result in
an integer overflow and subsequent buffer overflow if it is close to
SIZE_MAX. It should fail if size is large enough for this to happen.
Further, it's not legal for a C object to be larger than
PTRDIFF_MAX (half of SIZE_MAX) as pointer arithmetic within it could
overflow. So return failure immediately if size is greater than that.
CVE-2021-31873
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Gbp-Pq: Name 0036-klibc-malloc-Fail-if-requested-size-PTRDIFF_MAX.patch
Ben Hutchings [Sun, 17 Jan 2016 19:50:28 +0000 (19:50 +0000)]
run-init: Add dry-run mode
Bug-Debian: https://bugs.debian.org/810965
initramfs-tools wants to validate the real init program before running
it, as there is no way out once it has exec'd run-init. This is
complicated by the increasing use of symlinks for /sbin/init and for
/sbin itself. We can't simply resolve them with 'readlink -f' because
any absolute symlinks will be resolved using the wrong root. Add a
dry-run mode (-n option) to run-init that goes as far as possible to
validate that the given init is executable.
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Gbp-Pq: Name run-init-add-dry-run-mode.patch
The direct socket syscalls are now implemented on i386, m68k and s390,
making socketcall() obsolete. However we need to keep klibc/unstable
working with the last stable kernel version (3.16) so we shouldn't use
them yet.
Gbp-Pq: Name syscalls-override-detection-of-direct-socket-syscalls-on-i386-m68k-s390.patch
If the gzip utilities are built without support for compression,
they will always attempt to carry out decompression even if the
command name and options don't imply that. Instead they should
fail with an explicit error in this case.
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Gbp-Pq: Name gzip-fix-silent-fallback-to-decompression.patch
On ppc64 the struct stat defined by klibc matches the kernel one.
However it contains implicit padding before the st_rdev field due to the
64-bit alignement. For internal reasons, klibc defines st_rdev as a pair
of 32-bit values (using the __stdev64 macro). They only need to be
32-bit aligned and as a consequence st->st_rdev is incorrectly defined.
The solution is to add an explicit padding in the structure. This fixes
the resume binary on ppc64 BE and LE, and probably other things.
Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
Gbp-Pq: Name klibc-ppc64-fix-struct-stat.patch
On the hppa arch (32bit userspace and 32 or 64bit kernel), the fstype
program fails to detect the filesystem. The reason for this failure
is, that fstype calls the pread() syscall, which has on some
architectures with 32bit userspace a different calling syntax. I
noticed this bug on hppa, but I assume s390 (32bit) and others might
run into similiar issues.
Signed-off-by: Helge Deller <deller@gmx.de>
Gbp-Pq: Name klibc-add-pread-and-pwrite-32bit-syscall-wrappers-for-parisc.patch
Currently we ensure the installed headers are readable by everyone,
but write permissions will depend on the current umask. Turn off the
group and other writable bits to ensure consistent results.
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Gbp-Pq: Name install-headers-with-consistent-mode.patch
Description: Adding mips64 specific chagnes.
Modeled on mips 32 and adapted for 64 bit ABI.
- MCONFIG: using existing klibc.ld scrpit
- crt0.S: adapted gp initialization
- setjmp.S: do not save floating-point state
Gbp-Pq: Name 0003-add-mips64-support-arch-mips64-specific.patch
Description: Added header files for mips64.
Modeled on mips 32 header files and adapted for 64 bit ABI.
- archsetjmp.h: do not save floating-point state
- asm.h: Symbolic register names for 64 bit ABI
Gbp-Pq: Name 0001-add-mips64-support-headers.patch
Update usr/include/arch/mips/archfcntl.h from kernel headers:
- Add definitions of O_PATH, O_TMPFILE
- Update value of O_SYNC to include __O_SYNC
- Add definitions of F_{SET,GET}OWN_EX, F_GETOWNER_UIDS,
F_OFD_{GETLK,SETLK,SETLKW}, F_OWNER_{TID,PID,PGRP}
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Gbp-Pq: Name mips-update-archfcntl-h.patch
This fixes a segmentation fault in the system call's error handling path with
dynamically-linked binaries on PowerPC64 little endian. The system call stub
wasn't loading up r2 with the appropriate TOC value in its global entry point.
The r2 setup code comes from the FUNC_START macro in gcc [1] and an equivalent
one can also be found in the LOCALENTRY macro in glibc [2].
On the ELFv2 ABI (see [1]):
- The global entry point is expected to load up r2 with the appropriate TOC
value for this function.
- The local entry point expects r2 to be set up to the current TOC.
The problem happened with dynamically-linked binaries because:
- the system call is an indirect call (via global entry point) from the binary
to the shared library, landing in the syscall stub (which didn't load up r2
with the TOC of the shared library)
- its branch to __syscall_error is a direct call (via local entry point) within
the shared library, landing in the function (which expects r2 to be set up to
that TOC)
- when the function attempts to store errno (in an address relative to the TOC),
that address incorrectly pointed to a read-only segment -- segmentation fault.
The problem didn't happen with statically-linked binaries because the TOC value
wasn't different on that case.
Thanks and credits to Alan Modra and Ulrich Weigand, for helping with this and
pointing out the solution.
This is the use case in initramfs to keep data from /run to /root/run
before calling switch_root().
copy_file() doesn't yet catch EINTR, but that seems less of an issue
in initramfs.
copy_file() and much logic out of copy() is from Ulrich Dangel.
Thank you for the collaboration on this blocker for
http://bugs.debian.org/627808
While we are it require move to have mv at least 2 arguments passed.
Signed-off-by: Ulrich Dangel <uli@spamt.net> Signed-off-by: maximilian attems <max@stro.at>
[bwh: This is no longer needed by initramfs-tools starting with version 0.121,
so can be dropped after the stretch release]
Steve Langasek [Mon, 28 Jun 2021 14:24:37 +0000 (15:24 +0100)]
Include the multiarch include directory in klcc's path
The multiarch include directory, /usr/include/<triplet>, needs to be
explicitly added to klcc's path; without this, klcc is incompatible
with recent Ubuntu versions of linux-libc-dev and fails to find any asm/
headers.
This change is safe to apply on non-multiarch-enabled systems, since
$(DEB_HOST_MULTIARCH) will evaluate empty. However, upstreaming should
probably wait until we have a way to get this path information in a
vendor-neutral manner.
Ben Hutchings [Sun, 14 Mar 2010 18:41:56 +0000 (18:41 +0000)]
Fix klibc Debian specific build trouble
Simply remove the headers_install invocation and rely on linux-libc-dev.
With these changes:
(the extra chmod was needed to allow for umask > 022) I could compile,
link and run this program:
#include <unistd.h>
int main(void)
{
write(1, "Hello world\n", 12);
return 0;
}
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
[ added multi arch support ] Signed-off-by: Colin Watson <cjwatson@ubuntu.com> Signed-off-by: maximilian attems <max@stro.at>
[ fixed cross building ] Signed-off-by: Marcin Juszkiewicz <marcin.juszkiewicz@linaro.org>
Gbp-Pq: Name klibc-linux-libc-dev
Ben Hutchings [Sun, 15 Jul 2018 20:53:39 +0000 (21:53 +0100)]
Never clean files in quilt status directory
The top-level "distclean" and "mrproper" targets delete zero-size
files in the source, perhaps assumed to be stamp files. This is fine
for actual source direcgtories, but disastrous for a quilt status
directory.
For each patch, quilt stores the previous versions of the modified
files in a subdirectory of .pc. If the patch creates a file, this
file will be empty. Removing it effectively removes the file creation
from the patch.
The .git directory is already excluded from the clean rules for
a similar reason, so do the same for .pc.
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Gbp-Pq: Name never-clean-files-in-quilt-status-directory.patch
* Never clean files in quilt status directory
* debian/rules: Use $(MAKE) for recursive make
* debian/rules: Change override_dh_auto_test rule to actually run tests
* Apply security fixes from 2.0.9 (Closes: #989505):
- malloc: Set errno on failure
- malloc: Fail if requested size > PTRDIFF_MAX (CVE-2021-31873)
- calloc: Fail if multiplication overflows (CVE-2021-31870)
- cpio: Fix possible integer overflow on 32-bit systems (CVE-2021-31872)
- cpio: Fix possible crash on 64-bit systems (CVE-2021-31871)
Ben Hutchings [Sun, 17 Jan 2016 19:50:28 +0000 (19:50 +0000)]
run-init: Add dry-run mode
initramfs-tools wants to validate the real init program before running
it, as there is no way out once it has exec'd run-init. This is
complicated by the increasing use of symlinks for /sbin/init and for
/sbin itself. We can't simply resolve them with 'readlink -f' because
any absolute symlinks will be resolved using the wrong root. Add a
dry-run mode (-n option) to run-init that goes as far as possible to
validate that the given init is executable.
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Gbp-Pq: Name run-init-add-dry-run-mode.patch
Ben Hutchings [Tue, 5 Jan 2016 21:11:41 +0000 (21:11 +0000)]
syscalls: Override detection of direct socket syscalls on i386, m68k, s390
The direct socket syscalls are now implemented on i386, m68k and s390,
making socketcall() obsolete. However we need to keep klibc/unstable
working with the last stable kernel version (3.16) so we shouldn't use
them yet.
Gbp-Pq: Name syscalls-override-detection-of-direct-socket-syscalls-on-i386-m68k-s390.patch
Ben Hutchings [Fri, 18 Sep 2015 19:59:17 +0000 (21:59 +0200)]
gzip: Fix silent fallback to decompression
If the gzip utilities are built without support for compression,
they will always attempt to carry out decompression even if the
command name and options don't imply that. Instead they should
fail with an explicit error in this case.
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Gbp-Pq: Name gzip-fix-silent-fallback-to-decompression.patch
On ppc64 the struct stat defined by klibc matches the kernel one.
However it contains implicit padding before the st_rdev field due to the
64-bit alignement. For internal reasons, klibc defines st_rdev as a pair
of 32-bit values (using the __stdev64 macro). They only need to be
32-bit aligned and as a consequence st->st_rdev is incorrectly defined.
The solution is to add an explicit padding in the structure. This fixes
the resume binary on ppc64 BE and LE, and probably other things.
Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
Gbp-Pq: Name klibc-ppc64-fix-struct-stat.patch
Add pread and pwrite 32bit syscall wrappers for parisc
On the hppa arch (32bit userspace and 32 or 64bit kernel), the fstype
program fails to detect the filesystem. The reason for this failure
is, that fstype calls the pread() syscall, which has on some
architectures with 32bit userspace a different calling syntax. I
noticed this bug on hppa, but I assume s390 (32bit) and others might
run into similiar issues.
Signed-off-by: Helge Deller <deller@gmx.de>
Gbp-Pq: Name klibc-add-pread-and-pwrite-32bit-syscall-wrappers-for-parisc.patch
Ben Hutchings [Wed, 9 Sep 2015 00:24:56 +0000 (01:24 +0100)]
Install headers with consistent mode
Currently we ensure the installed headers are readable by everyone,
but write permissions will depend on the current umask. Turn off the
group and other writable bits to ensure consistent results.
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Gbp-Pq: Name install-headers-with-consistent-mode.patch
Dejan Latinovic [Fri, 6 Mar 2015 00:51:45 +0000 (16:51 -0800)]
add-mips64-support-arch-mips64-specific
Description: Adding mips64 specific chagnes.
Modeled on mips 32 and adapted for 64 bit ABI.
- MCONFIG: using existing klibc.ld scrpit
- crt0.S: adapted gp initialization
- setjmp.S: do not save floating-point state
Gbp-Pq: Name 0003-add-mips64-support-arch-mips64-specific.patch
Dejan Latinovic [Fri, 6 Mar 2015 00:51:44 +0000 (16:51 -0800)]
add-mips64-support-headers
Description: Added header files for mips64.
Modeled on mips 32 header files and adapted for 64 bit ABI.
- archsetjmp.h: do not save floating-point state
- asm.h: Symbolic register names for 64 bit ABI
Gbp-Pq: Name 0001-add-mips64-support-headers.patch
Ben Hutchings [Sun, 5 Oct 2014 00:08:21 +0000 (01:08 +0100)]
MIPS: Update archfcntl.h
Update usr/include/arch/mips/archfcntl.h from kernel headers:
- Add definitions of O_PATH, O_TMPFILE
- Update value of O_SYNC to include __O_SYNC
- Add definitions of F_{SET,GET}OWN_EX, F_GETOWNER_UIDS,
F_OFD_{GETLK,SETLK,SETLKW}, F_OWNER_{TID,PID,PGRP}
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Gbp-Pq: Name mips-update-archfcntl-h.patch
This fixes a segmentation fault in the system call's error handling path with
dynamically-linked binaries on PowerPC64 little endian. The system call stub
wasn't loading up r2 with the appropriate TOC value in its global entry point.
The r2 setup code comes from the FUNC_START macro in gcc [1] and an equivalent
one can also be found in the LOCALENTRY macro in glibc [2].
On the ELFv2 ABI (see [1]):
- The global entry point is expected to load up r2 with the appropriate TOC
value for this function.
- The local entry point expects r2 to be set up to the current TOC.
The problem happened with dynamically-linked binaries because:
- the system call is an indirect call (via global entry point) from the binary
to the shared library, landing in the syscall stub (which didn't load up r2
with the TOC of the shared library)
- its branch to __syscall_error is a direct call (via local entry point) within
the shared library, landing in the function (which expects r2 to be set up to
that TOC)
- when the function attempts to store errno (in an address relative to the TOC),
that address incorrectly pointed to a read-only segment -- segmentation fault.
The problem didn't happen with statically-linked binaries because the TOC value
wasn't different on that case.
Thanks and credits to Alan Modra and Ulrich Weigand, for helping with this and
pointing out the solution.
This is the use case in initramfs to keep data from /run to /root/run
before calling switch_root().
copy_file() doesn't yet catch EINTR, but that seems less of an issue
in initramfs.
copy_file() and much logic out of copy() is from Ulrich Dangel.
Thank you for the collaboration on this blocker for
http://bugs.debian.org/627808
While we are it require move to have mv at least 2 arguments passed.
Signed-off-by: Ulrich Dangel <uli@spamt.net> Signed-off-by: maximilian attems <max@stro.at>
[bwh: This is no longer needed by initramfs-tools starting with version 0.121,
so can be dropped after the stretch release]
Ben Hutchings [Sun, 14 Mar 2010 18:41:56 +0000 (18:41 +0000)]
Fix klibc Debian specific build trouble
Simply remove the headers_install invocation and rely on linux-libc-dev.
With these changes:
(the extra chmod was needed to allow for umask > 022) I could compile,
link and run this program:
#include <unistd.h>
int main(void)
{
write(1, "Hello world\n", 12);
return 0;
}
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
[ added multi arch support ] Signed-off-by: Colin Watson <cjwatson@ubuntu.com> Signed-off-by: maximilian attems <max@stro.at>
[ fixed cross building ] Signed-off-by: Marcin Juszkiewicz <marcin.juszkiewicz@linaro.org>
Gbp-Pq: Name klibc-linux-libc-dev
[changes brought forward from 2.0.4-2+rpi1 by Peter Michael Green <plugwash@p10link.net> at Wed, 26 Nov 2014 22:01:00 +0000]
* Change compiler settings to values suitable for raspberry pi
Ben Hutchings [Sun, 17 Jan 2016 19:50:28 +0000 (19:50 +0000)]
run-init: Add dry-run mode
initramfs-tools wants to validate the real init program before running
it, as there is no way out once it has exec'd run-init. This is
complicated by the increasing use of symlinks for /sbin/init and for
/sbin itself. We can't simply resolve them with 'readlink -f' because
any absolute symlinks will be resolved using the wrong root. Add a
dry-run mode (-n option) to run-init that goes as far as possible to
validate that the given init is executable.
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Gbp-Pq: Name run-init-add-dry-run-mode.patch
Ben Hutchings [Tue, 5 Jan 2016 21:11:41 +0000 (21:11 +0000)]
syscalls: Override detection of direct socket syscalls on i386, m68k, s390
The direct socket syscalls are now implemented on i386, m68k and s390,
making socketcall() obsolete. However we need to keep klibc/unstable
working with the last stable kernel version (3.16) so we shouldn't use
them yet.
Gbp-Pq: Name syscalls-override-detection-of-direct-socket-syscalls-on-i386-m68k-s390.patch
Ben Hutchings [Fri, 18 Sep 2015 19:59:17 +0000 (21:59 +0200)]
gzip: Fix silent fallback to decompression
If the gzip utilities are built without support for compression,
they will always attempt to carry out decompression even if the
command name and options don't imply that. Instead they should
fail with an explicit error in this case.
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Gbp-Pq: Name gzip-fix-silent-fallback-to-decompression.patch
On ppc64 the struct stat defined by klibc matches the kernel one.
However it contains implicit padding before the st_rdev field due to the
64-bit alignement. For internal reasons, klibc defines st_rdev as a pair
of 32-bit values (using the __stdev64 macro). They only need to be
32-bit aligned and as a consequence st->st_rdev is incorrectly defined.
The solution is to add an explicit padding in the structure. This fixes
the resume binary on ppc64 BE and LE, and probably other things.
Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
Gbp-Pq: Name klibc-ppc64-fix-struct-stat.patch
Add pread and pwrite 32bit syscall wrappers for parisc
On the hppa arch (32bit userspace and 32 or 64bit kernel), the fstype
program fails to detect the filesystem. The reason for this failure
is, that fstype calls the pread() syscall, which has on some
architectures with 32bit userspace a different calling syntax. I
noticed this bug on hppa, but I assume s390 (32bit) and others might
run into similiar issues.
Signed-off-by: Helge Deller <deller@gmx.de>
Gbp-Pq: Name klibc-add-pread-and-pwrite-32bit-syscall-wrappers-for-parisc.patch
Ben Hutchings [Wed, 9 Sep 2015 00:24:56 +0000 (01:24 +0100)]
Install headers with consistent mode
Currently we ensure the installed headers are readable by everyone,
but write permissions will depend on the current umask. Turn off the
group and other writable bits to ensure consistent results.
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Gbp-Pq: Name install-headers-with-consistent-mode.patch
Dejan Latinovic [Fri, 6 Mar 2015 00:51:45 +0000 (16:51 -0800)]
add-mips64-support-arch-mips64-specific
Description: Adding mips64 specific chagnes.
Modeled on mips 32 and adapted for 64 bit ABI.
- MCONFIG: using existing klibc.ld scrpit
- crt0.S: adapted gp initialization
- setjmp.S: do not save floating-point state
Gbp-Pq: Name 0003-add-mips64-support-arch-mips64-specific.patch
Dejan Latinovic [Fri, 6 Mar 2015 00:51:44 +0000 (16:51 -0800)]
add-mips64-support-headers
Description: Added header files for mips64.
Modeled on mips 32 header files and adapted for 64 bit ABI.
- archsetjmp.h: do not save floating-point state
- asm.h: Symbolic register names for 64 bit ABI
Gbp-Pq: Name 0001-add-mips64-support-headers.patch
Ben Hutchings [Sun, 5 Oct 2014 00:08:21 +0000 (01:08 +0100)]
MIPS: Update archfcntl.h
Update usr/include/arch/mips/archfcntl.h from kernel headers:
- Add definitions of O_PATH, O_TMPFILE
- Update value of O_SYNC to include __O_SYNC
- Add definitions of F_{SET,GET}OWN_EX, F_GETOWNER_UIDS,
F_OFD_{GETLK,SETLK,SETLKW}, F_OWNER_{TID,PID,PGRP}
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Gbp-Pq: Name mips-update-archfcntl-h.patch
This fixes a segmentation fault in the system call's error handling path with
dynamically-linked binaries on PowerPC64 little endian. The system call stub
wasn't loading up r2 with the appropriate TOC value in its global entry point.
The r2 setup code comes from the FUNC_START macro in gcc [1] and an equivalent
one can also be found in the LOCALENTRY macro in glibc [2].
On the ELFv2 ABI (see [1]):
- The global entry point is expected to load up r2 with the appropriate TOC
value for this function.
- The local entry point expects r2 to be set up to the current TOC.
The problem happened with dynamically-linked binaries because:
- the system call is an indirect call (via global entry point) from the binary
to the shared library, landing in the syscall stub (which didn't load up r2
with the TOC of the shared library)
- its branch to __syscall_error is a direct call (via local entry point) within
the shared library, landing in the function (which expects r2 to be set up to
that TOC)
- when the function attempts to store errno (in an address relative to the TOC),
that address incorrectly pointed to a read-only segment -- segmentation fault.
The problem didn't happen with statically-linked binaries because the TOC value
wasn't different on that case.
Thanks and credits to Alan Modra and Ulrich Weigand, for helping with this and
pointing out the solution.
This is the use case in initramfs to keep data from /run to /root/run
before calling switch_root().
copy_file() doesn't yet catch EINTR, but that seems less of an issue
in initramfs.
copy_file() and much logic out of copy() is from Ulrich Dangel.
Thank you for the collaboration on this blocker for
http://bugs.debian.org/627808
While we are it require move to have mv at least 2 arguments passed.
Signed-off-by: Ulrich Dangel <uli@spamt.net> Signed-off-by: maximilian attems <max@stro.at>
[bwh: This is no longer needed by initramfs-tools starting with version 0.121,
so can be dropped after the stretch release]
Ben Hutchings [Sun, 14 Mar 2010 18:41:56 +0000 (18:41 +0000)]
Fix klibc Debian specific build trouble
Simply remove the headers_install invocation and rely on linux-libc-dev.
With these changes:
(the extra chmod was needed to allow for umask > 022) I could compile,
link and run this program:
#include <unistd.h>
int main(void)
{
write(1, "Hello world\n", 12);
return 0;
}
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
[ added multi arch support ] Signed-off-by: Colin Watson <cjwatson@ubuntu.com> Signed-off-by: maximilian attems <max@stro.at>
[ fixed cross building ] Signed-off-by: Marcin Juszkiewicz <marcin.juszkiewicz@linaro.org>
Gbp-Pq: Name klibc-linux-libc-dev
Ben Hutchings [Sun, 8 May 2016 20:59:37 +0000 (20:59 +0000)]
klibc (2.0.4-9) unstable; urgency=medium
* Change dh_fixperms arguments to restore binary reproducibility
* initramfs-tools: Ensure busybox's hook runs before ours if it is
going to be used in the initramfs (Closes: #823323)
Ben Hutchings [Sun, 5 Oct 2014 00:08:21 +0000 (01:08 +0100)]
MIPS: Update archfcntl.h
Update usr/include/arch/mips/archfcntl.h from kernel headers:
- Add definitions of O_PATH, O_TMPFILE
- Update value of O_SYNC to include __O_SYNC
- Add definitions of F_{SET,GET}OWN_EX, F_GETOWNER_UIDS,
F_OFD_{GETLK,SETLK,SETLKW}, F_OWNER_{TID,PID,PGRP}
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Gbp-Pq: Name mips-update-archfcntl-h.patch
This fixes a segmentation fault in the system call's error handling path with
dynamically-linked binaries on PowerPC64 little endian. The system call stub
wasn't loading up r2 with the appropriate TOC value in its global entry point.
The r2 setup code comes from the FUNC_START macro in gcc [1] and an equivalent
one can also be found in the LOCALENTRY macro in glibc [2].
On the ELFv2 ABI (see [1]):
- The global entry point is expected to load up r2 with the appropriate TOC
value for this function.
- The local entry point expects r2 to be set up to the current TOC.
The problem happened with dynamically-linked binaries because:
- the system call is an indirect call (via global entry point) from the binary
to the shared library, landing in the syscall stub (which didn't load up r2
with the TOC of the shared library)
- its branch to __syscall_error is a direct call (via local entry point) within
the shared library, landing in the function (which expects r2 to be set up to
that TOC)
- when the function attempts to store errno (in an address relative to the TOC),
that address incorrectly pointed to a read-only segment -- segmentation fault.
The problem didn't happen with statically-linked binaries because the TOC value
wasn't different on that case.
Thanks and credits to Alan Modra and Ulrich Weigand, for helping with this and
pointing out the solution.
Simply remove the headers_install invocation and rely on linux-libc-dev.
With these changes:
(the extra chmod was needed to allow for umask > 022) I could compile,
link and run this program:
#include <unistd.h>
int main(void)
{
write(1, "Hello world\n", 12);
return 0;
}
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
[ added multi arch support ] Signed-off-by: Colin Watson <cjwatson@ubuntu.com> Signed-off-by: maximilian attems <max@stro.at>
[ fixed cross building ] Signed-off-by: Marcin Juszkiewicz <marcin.juszkiewicz@linaro.org>
Gbp-Pq: Name klibc-linux-libc-dev
projects / klibc.git / log